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The controller serves in particular for steering functions in motor; vehicles (motor control, 
transmission price increase etc.). It; exhibits a processor (1), which is provided with RAM and 
read-only; memories (3, 4). Working off trials or tasks is coordinated temporally; -and steered 
by the operating system. It is both for the treatment of; tasks according to a batch processing 
method (non preemptive; scheduling), with which processing a current task not be 
interrupted; cannot, and for the treatment of tasks according to a displacement; method 
(preemptive scheduling), with which processing a task for; working off another task be 
interrupted can, furnished. The kind of; processing is attached to each task as attribute, by 
which the; respective method of handling is specified. 

EXEMPLARY CLAIMS- 1. Controller (1), in particular to steering functions in motor vehicles, 
that with a processor (2), with data memories (3, 4), also-and expenditure circuits (6) as well 
as with an operating system provided is characterized, by which the processing of tasks is 
coordinated temporally and steered, by it, that the operating system is furnished both for the 
treatment of tasks according to a batch processing method (nonpreemptive 5 scheduling), 
with which processing a task not be interrupted cannot and for the treatment of tasks 
according to a displacement method (preemptive scheduling), with that the processing of a 
task for 10 processing another task are interrupted can, and 2. Operating system for a 
controller (1), to steering functions in motor vehicles, by which the processing of tasks is 
coordinated temporally and steered by the controller, by it are in particular marked, that tasks 
worked on both according to a batch processing method (nonpreemptive scheduling), with 
which processing a task not be interrupted cannot and according to a displacement method, 
with 25 that processing a task for processing another task be interrupted can (preemptive 
scheduling), and that the kind of the processing each task as attribute one assigns, by which 
jewei-the 30 lige processing method is specified. 
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@ Steuergerat und Betriebssystem fur dieses Steuergerat 

@ Das Steuergerat dient insbesondere zum Steuern von 
Funktionen in Kraftfahrzeugen (Motorsteuerung, Getriebe- 
steuerung usw.). Es weist einen Prozessor (1) auf, der mit 
RAM- und Festwertspeichern (3, 4) versehen ist. Durch das 
Betriebssystem wird das Abarbeiten von Prozessen oder 
Tasks zeitlich koordiniert und gesteuert. Es ist sowohl fur die 
Bearbeitung von Tasks nach einer Stapelverarbeitungsme- 
thode (non-preemptive scheduling), bei der die Abarbeitung 
einer laufenden Task nicht unterbrochen werden kann, als 
auch fur die Bearbeitung von Tasks nach einer Verdran- 
gungsmethode (preemptive scheduling), bei der die Abar- 
beitung einer Task zum Abarbeiten einer anderen Task 
unterbrochen werden kann, eingerichtet. Die Art der Abar- 
beitung wird jeder Task als Attribut zugeordnet, durch das 
die jeweilige Bearbeitungsmethode festgelegt wird. 
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Beschreibung 

Die Erfindung betrifft ein Steuergerat nach dem 
Oberbegriff von Patentanspruch 1 und ein Betriebssy- 
stem nach dem Oberbegriff von Anspruch 2. 5 

Bei einer bekannten Motorsteuerung 
(DE 38 26 526 Al) laufen Programme unterschiedlicher 
zeitlicher Prioritat ab. Dabei sind Programme prioritats- 
hoch, mit denen bei einem vorgegebenen Kurbelwinkel 
ein Motorsteuervorgang ausgelost wird, z. B. Kraftstoff 10 
eingespritzt oder das Kraftstoff-Luft-Gemisch gezundet 
wird. Mit niedriger Prioritat laufen sogenannte Hinter- 
grundprogramme ab. 

Bei dem Entwurf von Steuerungen wird die von dem 
Steuergerat zu erledigende Steuerungsaufgabe iibli- 15 
cherweise in Teilaufgaben gegliedert und jede Teilauf- 
gabe als ein in sich abgeschlossenes Programm reali- 
siert. Ein solches Programm wird als Task — oder auch 
als ProzeB oder Teilaufgabe — bezeichnet. Betriebssy- 
steme die mehrere Tasks verwalten konnen, werden als 20 
Multitasking- Betriebssysteme bezeichnet. 

Bei der Durchfuhrung der Steuerungsaufgaben tritt 
haufig eine Situation auf, bei der sich mehrere Tasks um 
die Benutzung der zentralen Rechnereinheit, der CPU, 
bemiihen. Die Aufgabe des Multitasking-Betriebssy- 25 
stems besteht darin, der CPU immer nur eine von meh- 
reren Tasks zuzuteilen. Der Teil des Betriebssystems, 
der die Taskwechsel vollzieht, wird als Dispatcher be- 
zeichnet. Derjenige Teil des Betriebssystems, der ent- 
scheidet, welcher Task die CPU zugeteilt wird, wird als 30 
Scheduler bezeichnet. 

Ein Taskwechsel kann von dem Betriebssystem 
grundsatzlich auf zwei verschiedene Arten durchge- 
fiihrt werden: 

35 

— nach einer Verdrangungsmethode — im folgen- 
den als "preemptive scheduling" bezeichnet — , bei 
der die Abarbeitung einer Task von dem Betriebs- 
system unterbrochen und die CPU einer anderen 
wartenden Task zugeteilt werden kann, und 40 

— nach einer Stapelverarbeitungsmethode — im 
folgenden: "non- preemptive scheduling" — , bei der 
eine laufende, d. h. derzeitig abgearbeitete Task 
nicht durch eine andere Task verdrangt werden 
kann. 45 

Bei dem preemptive scheduling benotigt das Be- 
triebssystem zusatzliche Rechnerzeit und Arbeitsspei- 
cherkapazitat, um die Daten der Task zu sichern, die 
unterbrochen wird und spater weiter bearbeitet werden 50 
muB. Bei dem non-preemptive scheduling muB beim 
Entwickeln der Programme fur das Steuergerat darauf 
geachtet werden, daB die Laufzeiten der einzelnen 
Tasks nicht die Echtzeitbedingungen des Systems ver- 
letzen. Es kann deshalb erforderlich sein, daB eine zu- 55 
sammenhangende Teilaufgabe in mehrere Tasks aufge- 
teilt werden muB. 

Beim Entwickeln und Programmieren von Steuerge- 
raten muB man sich bislang fiir eine der Betriebssystem- 
arten entscheiden. Entweder entscheidet sich der Ent- 60 
wickler fur ein non-preemptive Betriebssystem, fiir das 
kein zusatzlicher Arbeitsspeicherplatz erforderlich ist, 
der Aufwand fiir die Programmerstellung aber hoher ist, 
oder er entscheidet sich fiir ein preemptive Betriebssy- 
stem, das zwar zusatzlichen Speicher benotigt, die Pro- 65 
grammerstellung aber vereinfacht. 

Der Erfindung liegt die Aufgabe zugrunde, ein Steu- 
ergerat und ein Betriebssystem fiir ein solches Steuerge- 
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rat zu schaffen, das den Aufwand fiir Hardware und 
Software verringert und die Verarbeitungskapazitat des 
Steuergerats mdglichst gut ausnutzt. 

Diese Aufgabe wird erfindungsgemaB durch das 
Steuergerat nach Anspruch 1 und das Betriebssystem 
nach Anspruch 2 gelost. 

Ein Ausfuhrungsbeispiel der Erfindung wird im fol- 
genden anhand der Zeichnung eriautert Es zeigen: 

Fig, 1 ein Steuergerat gemaB der Erfindung in Block- 
diagrammdarstellung, 

Fig. 2 die verschiedenen Zustande, die eine in dem 
Steuergerat nach Fig. 1 abzuarbeitende Task einneh- 
men kann, 

Fig. 3 eine Taskfolge bei einem Betriebssystem mit 
preemptive scheduling, 

Fig. 4 eine Taskfolge bei einem Betriebssystem mit 
non- preemptive scheduling, und 

Fig. 5 eine Taskfolge bei einem erfindungsgemaBen 
Betriebssystem mit mixed-preemptive scheduling. 

Ein Steuergerat 1 (Fig. 1) weist einen Zentralprozes- 
sor oder CPU 2, einen Arbeitsspeicher oder RAM 3, 
einen Festwertspeicher oder EPROM 4 sowie Ein- und 
Ausgabeschaltungen oder I/O-Ports 6 auf. Diese Schal- 
tungsbestandteile sind durch Daten- und Signalleitun- 
gen 7 bis 10 und ein Bussystem 11 untereinander ver- 
bunden. An den I/O- Port 6 sind eine Eingangsleitung 12 
und Ausgangsleitung 13 angeschlossen, iiber die das 
Steuergerat 1 mit dem zu steuernden System, z, B. mit 
der Einspritzanlage, der Ziindsteuerung, der Getriebe- 
steuerung usw. des Kraftfahrzeugs verbunden ist. Ober 
die Eingangsleitung 12 gelangen die von hier nicht dar- 
gestellten Sensoren gelieferten MeBwerte zu dem Steu- 
ergerat, iiber die Leitung 13 werden von diesem Steuer- 
signale an eine ebenfalls nicht dargestellte Einrichtung, 
z. B. eine Motorsteuerung, ausgegeben. 

Eine in dem Steuergerat 1 abzuarbeitende Task kann 
vier verschiedene Zustande (Taskzustande) einnehmen, 
die aus Fig. 2 ersichtlich sind: 

— Ruhend: Die Task belegt keine Betriebsmittel; 
sie bleibt in diesem Zustand, bis sie von einer ande- 
ren Task oder dem Betriebssystem gestartet wird. 

— Bereit: Die Task bewirbt sich um die Zuteilung 
der CPU 2. 

— Laufend (oder Aktiv): Die Task hat die CPU 2 
zugeteilt bekommen und wird von dieser abgear- 
beitet 

— Wartend: Die Task wartet auf ein Ereignis, z. B. 
auf das Ergebnis einer anderen Task. Tritt dieses 
Ereignis ein, so wird die Task freigegeben und ge- 
langt in den Zustand Bereit 

Der Taskwechselmechanismus kann nach einer der 
eingangs angegebenen Methoden, der Stapelverarbei- 
tung oder der Verdrangungsmethode, erfolgen. 

Bei der Verdrangungsmethode oder preemptive 
scheduling kann eine laufende Task (z. B. durch einen 
Interrupt) von dem Betriebssystem unterbrochen und 
die CPU 2 einer anderen wartenden Task zugeteilt wer- 
den, wie nun anhand von Fig. 3 eriautert wird. 

In dem dargestellten Beispiel werden drei Tasks a, b 
und c betrachtet, wobei die Task a eine hohere Prioritat 
als die Tasks b und c und die Task b eine hohere Priori- 
tat als die Task c hat. Zu einem Zeitpunkt to warten die 
hoherprioren Task a und b auf ein Ereignis, wahrend die 
Task c lauft, d. h. abgearbeitet wird. 

Zu einem Zeitpunkt ti tritt ein Ereignis — ein Inter- 
rupt — fiir die Task b ein. Der Dispatcher und der 
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Scheduler werden gestartet. Da auBer der Task c eine 
hdherpriore Task bereit ist, wird die Task c unterbro- 
chen und ihrTaskkontext gerettet. 

Unter dem Taskkontext wird hier die Datengesamt- 
heit verstanden, die erforderlich ist, urn die unterbroche- 5 
ne Task spater fortzusetzen. Im wesentlichen besteht 
der Taskkontext aus dem Inhalt der - hier nicht darge- 
stellten, da allgemein bekannt - Register der CPU 2. 

Die Task b wird gestartet. 

Zu einern Zeitpunkt t 2 tritt ein Ereignis (Interrupt) fur 10 
die Task a ein. Der Dispatcher und der Scheduler wer- 
den gestartet. Da neben der Tasks b und c die hdher- 
priore Task a bereit ist, wird die Task b unterbrochen 
und ihr Taskkontext gerettet. Die Task a wird gestartet 

Zu einem Zeitpunkt t 3 ist die Task a beendet. Der 15 
Dispatcher und der Scheduler werden gestartet. Von 
den dann bereiten Tasks hat die Task b die hochste 
Prioritat. Da diese unterbrochen worden ist, restauriert 
der Dispatcher ihren Kontext. AnschlieBend kann die 
Task fortgesetzt werden, d. h. ihre noch nicht abgearbei- 20 
teten Befehle werden nun abgearbeitet 

Zu einem Zeitpunkt u ist die Task b beendet. Der 
Dispatcher und der Scheduler werden gestartet. Zu die- 
sem Zeitpunkt ist nur noch die Task c bereit. Da diese 
unterbrochen worden war, restauriert der Dispatcher 25 
ihren Kontext. AnschlieBend kann die Task b mit ihrer 
Befehlsfolge weiter durchgefuhrt werden. 

Da die Tasks mitten in ihrer Befehlsfolge von hoher- 
prioren Tasks unterbrochen werden konnen, muB im 
Falle einer Unterbrechung der Dispatcher den 30 
Taskkontext retten. Dazu wird der Taskkontext tempo- 
rar in einem Bereich des RAM-Speichers 3 zwischenge- 
speichert. Wenn nach einem Taskwechsel die unterbro- 
chene Task die CPU wieder zugeteilt bekommt, wie z. B. 
die Task b zu dem Zeitpunkt t 3) muB der Dispatcher 35 
zuerst den Taskkontext wieder restaurieren. 

Da die Tasks hier von "wichtigeren" Tasks verdrangt 
werden kdnnen, braucht bei der Entwicklung des Pro- 
gramms die Lange einer Task nicht beriicksichtigt zu 
werden. Da in dem Beispiel die Task c von hoherprioren 40 
Task unterbrochen werden kann, kann diese Task belie- 
big lang sein, ohne daB Echtzeitverhalten fur hoherprio- 
rer Tasks und damit das Echtzeitverhalten des Steuer- 
gerats zu gefahrden. Allerdings benotigt das Steuerge- 
rat fur die Rettung des Taskkontextes wie erwahnt zu- 45 
satzliche Rechenzeit und RAM-Speicherplatz, und zwar 
in Abhangigkeit von dem Umfang des Kontextes und 
der Gesamtzahl der Tasks. 

Bei der non-preemptive scheduling oder Stapelverar- 
beitungsmethode kann eine laufende Task nicht durch 50 
eine andere Task verdrangt, d. h. unterbrochen werden. 
Dies ist in Fig. 4 dargestellt. 

Auch in diesem Beispiel stehen drei Tasks a, b und c 
an, von denen die Task a eine hohere Prioritat als die 
Tasks b und c und die Task b eine hohere Prioritat als 55 
die Task c hat. Zu einem Zeitpunkt t 0 warten die hoher- 
prioren Tasks a und b auf ein Ereignis, wahrend die Task 
c lauft, d. h. abgearbeitet wird. 

Zu einem Zeitpunkt ti tritt ein Ereignis (Interrupt) fQr 
die Task b ein. Die Task b gelangt deshalb in den Zu- eo 
stand Bereit. Da laufende Tasks nicht unterbrochen 
werden konnen, muB die Task b bis zu einem Zeitpunkt 
t 2 warten, zu dem die Task c beendet worden ist und die 
Task b gestartet werden kann. 

Zu einem Zeitpunkt t 3 tritt ein Ereignis (Interrupt) fur 65 
die Task a ein. Die Task gelangt deshalb in den Zustand 
Bereit. Da laufende Tasks nicht unterbrochen werden 
konnen, muB die Task a bis zu einem Zeitpunkt t 4 war- 
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ten. Zu diesem Zeitpunkt ist die Task b beendet und die 
Task a kann gestartet werden. 

Da die Tasks hier nicht von hdherprioren Tasks un- 
terbrochen werden konnen, muB der Dispatcher den 
Taskkontext weder retten noch restaurieren. Es wird 
kein Speicherplatz in dem RAM-Speicher 3 belegt. Da 
die Tasks nicht unterbrochen werden konnen, muB an- 
dererseits der Entwickler des Programms darauf achten, 
daB die Laufzeit einer Task nicht die Echtzeitbedingun- 
gen verietzt. Dabei kann zusatzlicher Programmierauf- 
wand erforderlich werden. 

Die Art des Taskwechselmechanismus wird deshalb 
hier einer Task als Attribut "preemptive scheduling" 
oder "non-preemptive scheduling" zugeordnet. Damit 
ergibt sich eine Abarbeitung der Taskfolge nach einem 
"mixed-preemptive scheduling", das aus Fig. 5 ersicht- 
lich ist. Auch hier liegen drei Tasks a, b und c vor, wobei 
die Task a eine hohere Prioritat als die Tasks b und c und 
die Task b eine hohere Prioritat als die Task c haben. 
Die Task c ist als eine preemptive Task und die Tasks a 
und b als eine non-preemptive Tasks deklariert. 

Zu einem Zeitpunkt to warten die hoherprioren Tasks 
a und b auf ein Ereignis; die Task c lauft. 

Zu einem Zeitpunkt tj tritt ein Ereignis (Interrupt) fur 
die Task b ein. Der Dispatcher und der Scheduler des 
Betriebssystems werden gestartet. Da neben der Task c 
eine hdherpriore Task bereit ist und auBerdem die Task 
c als eine preemptive Task deklariert ist, wird die Task c 
unterbrochen und ihr Taskkontext gerettet. Die Task b 
wird gestartet. 

Zu einem Zeitpunkt t 2 tritt ein Ereignis (Interrupt) fur 
die Task a ein. Die Task gelangt deshalb in den Zustand 
bereit. Da die laufende Task b als non-preemptive de- 
klariert ist, kann sie nicht unterbrochen werden: Die 
Task a muB bis zu einem Zeitpunkt t3 warten, zu dem 
die Task b beendet worden ist und die Task a gestartet 
werden kann. 

Zu einem Zeitpunkt U ist die Task a beendet. Der 
Dispatcher und der Scheduler des Betriebssystems wer- 
den gestartet. Zu diesem Zeitpunkt ist nur noch die Task 
c bereit. Da diese unterbrochen wurde, restauriert der 
Dispatcher ihren Kontext. AnschlieBend kann die Task 
mit ihrer Befehlsfolge weiter verarbeitet werden. Da als 
"preemptive" deklarierte Tasks mitten in der Befehlsfol- 
ge von hoherprioren Tasks unterbrochen werden k6n- 
nen, muB der Dispatcher nur fur diese Tasks den 
Taskkontext, d. h. z. B. den Inhalt der CPU-Register ret- 
ten. 

Das hier beschriebene mixed-preemptive scheduling 
oder kombinierte Multitasking-Betriebssystem ermog- 
licht es, bei der Entwicklung eines Steuerungssystems 
Tasks entweder als preemptive oder non-preemptive zu 
deklarieren: Nur fur die als preemptive deklarierten 
Tasks muB Rechenzeit und RAM-Speicherbereich be- 
reitgestellt werden, und nur bei den als non-preemptive 
deklarierten Tasks muB der Entwickler darauf achten, 
daB die Lange der Tasks nicht die Echtzeitbedingungen 
fur das Steuerungssystem verietzt. Unter Inkaufnahme 
eines geringen Zusatzaufwands werden die Vorteile der 
beiden bekannten Betriebssysteme genutzt. 

PatentansprQche 

1. Steuergerat (1), insbesondere zum Steuern von 
Funktionen in Kraftfahrzeugen, das mit einem Pro- 
zessor (2), mit Datenspeichern (3, 4), mit Ein- und 
Ausgabeschaltungen (6) sowie mit einem Betriebs- 
system versehen ist, durch das die Abarbeitung von 
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Tasks zeitlich koordiniert und gesteuert wird, da» 
durch gekennzeichnet, 

— daB das Betriebssystem eingerichtet ist so- 
wohl fiir die Bearbeitung von Tasks nach einer 
Stapelverarbeitungsmethode (non-preemptive 5 
scheduling), bei der die Abarbeitung einer 
Task nicht unterbrochen werden kann, als 
auch fUr die Bearbeitung von Tasks nach einer 
Verdrangungsmethode (preemptive schedu- 
ling), bei der die Abarbeitung einer Task zum 10 
Abarbeiten einer anderen Task unterbrochen 
werden kann, und 

— daB die Art der Abarbeitung jeder Task als 
Attribut zugeordnet ist, durch das die jeweilige 
Bearbeitungsmethode festgelegt wird. 15 

2 Betriebssystem fur ein Steuergerat (1), insbeson- 
dere zum Steuern von Funktionen in Kraftfahrzeu- 
gen, durch das die Abarbeitung von Tasks durch 
das Steuergerat zeitlich koordiniert und gesteuert 
wird, dadurch gekennzeichnet, 2 o 

— daB Tasks bearbeitet werden sowohl nach 
einer Stapelverarbeitungsmethode (non-pre- 
emptive scheduling), bei der das Abarbeiten 
einer Task nicht unterbrochen werden kann, 
als auch nach einer Verdrangungsmethode, bei 25 
der das Abarbeiten einer Task zum Abarbei- 
ten einer anderen Task unterbrochen werden 
kann (preemptive scheduling), und 

— daB die Art der Verarbeitung jeder Task als 
Attribut zugeordnet wird, durch das die jewei- 30 
lige Abarbeitungsmethode festgelegt wird 



Hierzu 3 Seite(n) Zeichnungen 



35 



40 



45 



50 



55 



60 



Leerseite 



Int. CI. 6 : G05B 19/042 

Offenlegungstag: 5. Oktober 1995 



t 



Steuergerat 



CPU 
(80C167) 



3 



I/O 



7 X ii^ 9 



RAM 



10 



EPROM 

/— 



12 



I Sensorwerte 



Ansteuerung 



/3 



Fig. 1 



508 040/103 



IntCI. 6 : G05B 19/042 

Offenlegungstag: 5. Oktober 1995 




Fig. 2 



:C0 
± % 

P I. 



Disp. & 
Sched. 



Task a: 



Task b: 



Task c: 



Ereignis Ereignis 
fur Task b fur Task a 




to 



t1 



t2 



t3 



t4 



Zeit 



F/ 3 . 3 



508 040/103 



ZEICHNUNGEN SEITE 3 



tCD 

<o .2 



iMUiimiei 



Dlsp. & 
Sched. 



Task a: 



Task b: 



Task c: 



Ereignis 
fur Task b 



Int. CI. 6 : 

Offenlegungstag: 

Ereignis 
fur Task a 



Wartend 


Wartend 
Bereit 




Laufend 







Laufend 



Bereit 



G05B 19/042 

5. Oktober1995 



Laufend 



Wartend 



Wartend 



to 



t1 



t2 t3 

Fig. * 



t4 



:C0 



Disp. & 
Sched. 



Task a: 
(non-pre.) 



Task b: 
(non-pre.) 

Task c: 
(pre.) 



Ereignis Ereignis 
fur Task b fur Task a 



Wartend 



Wartend 



Laufend 



to 



t1 



Bereit 



Laufend 



Bereit 



Laufend 



Wartend 



Wartend 



Laufend 



t2 



t3 

Ffg.S 



t4 



Zeit 



508 040/1 03 



